It is well known today that a wireless handset such as a cell phone can be equipped with a web browser to support requesting, receiving and rendering of web content. Like PC-based browsers, a typical cell phone browser will use HTTP messaging or some variant of HTTP messaging to request and receive web content. For instance, the browser may send to a web server an HTTP GET request specifying desired content and may then receive from the web server an HTTP 200 OK request carrying the requested content.
In many cases, the content returned by the web server will comprise an HTML markup document or the like, which may include text, object-references, and formatting directives, among other elements. Each object-reference will typically point to an image file, music file, multimedia file (e.g., audio/video file) or other object at a particular location specified by a Universal Resource Indicator (URI). When the browser receives the markup document, the browser will then automatically respond to each such object reference by sending a respective secondary HTTP request or the like, in order to download the referenced object for presentation to a user. The browser will then present the text and objects in the manner indicated by the markup.
To speed up rendering of frequently accessed content, most browsers are also arranged to cache referenced objects in local data storage. Each time the browser receives a referenced object, the browser may store the object in its local cache, typically with an indication of the URI from which it was obtained, and typically with an expiration timer. When the browser receives a markup document that references an object the browser has cached (i.e., from the same URI), the browser may then conveniently use the cached copy of the object rather than having to download a new copy of the object. When the expiration timer for a given cached object expires, the browser may automatically delete the object from cache, to conserve storage space. Thereafter, if the browser receives a markup document that references the object, the browser would again download the object for presentation to a user.
When a web server sends an object such as an image file to browser, the server typically provides the object in binary form within the body of an HTTP 200 OK message, including a MIME (“Multipurpose Internet Mail Extension”) header that specifies the content type. Based on the content type indicated in the MIME header, the browser can then invoke applicable logic to render the object for presentation. For instance, if the object is a JPEG image file, the browser can invoke logic to render the file as an image on a display screen.
Many browsers are also capable of receiving and rendering web content that arrives in the form of a multi-part MIME package. Most commonly used for HTML-based e-mail messaging, a multi-part MIME package may include a root part that contains a markup document, and then one or more other parts that each contain a respective object having a designated MIME content type indicated by a MIME header. For instance, one part may contain one image file, and another part may contain another image file, while yet another part may contain another sort of object, and so forth. When a browser receives such a package, the browser may render the content as indicated by the primary markup document, which may include presenting the included objects.
In certain client stations, it is also highly desirable to more permanently store certain objects, such as image files, to be presented when rendering web content. In a cell phone that is arranged to frequently access particular web pages, for instance, it is desirable to more permanently store a set of objects that will need to be presented when rendering those particular web pages. That way, the cell phone will not have to download the objects or cache the objects, and no risk would exist that the objects would expire and be deleted from cache.
By way of example, assume that a wireless carrier maintains a home page to which cell phones issued by the carrier are programmed to browse. Assume further that the home page includes the carrier's logo and certain other graphical image elements, such as fanciful button images for instance. To facilitate quick rendering of the home page, and to avoid unnecessary wireless data transmission (which can be costly), the carrier may pre-provision all of its subscribers' cell phones with the necessary image files. That is, the carrier (or a manufacturer or vendor of the cell phones) may load the image files into a defined storage location on each cell phone. (Since these objects are not cached in the traditional browser sense but are rather stored in a more fixed manner, the objects may be considered “non-cached objects.” Non-cached image files may also be referred to as “pictograms.”)
The carrier can then design its home page HTML document to point to locally-stored objects rather than to network-based versions of the objects. For instance, where the home page HTML document references the carrier's logo image, it may do so with a URI that points to a path/filename in the cell phone rather than with a URI that points to a file on a remote network server. Conveniently, when a browser on such a cell phone receives the home page HTML document that points to one or more locally-stored objects, the browser would then quickly and easily retrieve the one or more objects from local storage, to facilitate presentation of the object(s) to a user.
With this arrangement, no need would exist for the cell phone browser to download the object(s). Further, no need would exist to cache the objects and consequently no risk would exist that the objects might expire and be deleted from cache. The end result would be a more seamless, quicker, and less expensive user experience.
Although storing and referencing objects locally on a cell phone or other client station is thus advantageous, the very fixed nature of the objects unfortunately presents a problem: if a need or desire arises to change any of the objects, doing so can be quite burdensome or impossible.
For instance, in the example above, if the carrier's logo changes, the logo image file stored locally on subscribers' cell phones would still be the old logo image. To force the home page to display the new logo, the carrier would need to redesign its HTML home page document to refer to a network-based image file of the new logo, which each cell phone would then need to download and perhaps cache, thus eliminating the benefit of having the logo be stored as a pictogram on the cell phone. Alternatively, the carrier could re-provision each cell phone (e.g., with a firmware update), either over-the-air or with a cable connection, in order to put the new logo image on the cell phone as a pictogram. These solutions are, unfortunately, burdensome. Therefore, an improved solution is desired.